Electronic Purse Applet Certi cation : extendedabstract 1

ion The logfull() byte code is modelled by an SMV [8] module that involves the following variables: pc: program counter; mem[i]: an array modelling the memory locations; stck[i]: an array modelling the operand stack; sP : stack pointer; ByteCode: the name of the current instruction. The values of the variables are abstracted into levels. Levels are de ned in a module called Levels in such a way that a level is represented by a boolean. Hence the types of abstracted variables are boolean or array of boolean. We do not abstract the value of the program counter that gives the sequencing of instructions, we keep unchanged the value of the stack pointer that gives the index of the rst empty slot and the value of the current instruction. L: levels; pc : -1..9; mem : array 0..1 of boolean; stck : array 0..1 of boolean; sP : -1..1; ByteCode : {invoke_108, load_0, return, nop, store_1, dup, load_1, getfield_220,op, putfield_220}; The byte code execution starts at program location 0. Initially, the stack is empty, the level of the method parameter is stored in memory location 0, it is equal to the level of the interaction we are analysing (i.e. level AF + P ) that is encoded as the conjunction of levels L:AF and L:P . init(pc):= 0; init(sP):= 1; init(mem[0]):= L.AF & L.P; for (i=0; i< 2; i=i+1) {init(stck[i]) := L.AF & L.P; } The control loop de nes the value of the program counter and of the current instruction. It is an almost direct translation of the Java byte code. When pc is equal to -1 then the execution is nished and the current instruction is nop that does nothing. As in [5], each instruction we consider models various instructions of the Java byte code. For instance, as we do not care about the type of memory and stack locations, instruction load 0 represents Java instructions (aload i, iload i, lload i,...). Similarly, the op instruction models all the binary operations as (iadd, ladd, iand, ior, ...). Although methods in the Electronic Purse case study tend to be rather short, the value domain of the pc variable is generally the larger domain in the SMV model we generate. As a large value domain can be a source of state explosion for model checkers, it is interesting to reduce it. We consider that 8 the next value of pc is pc + 1 (except of course in the case of conditional or jump instructions). In this example, the domain of pc is -1..9 that is smaller that the original domain 0..15. (next(pc), ByteCode) := switch(pc) { -1: (-1, nop); 0 : (pc+1, load_0 ); 1 : (pc+1, invoke_108 ); 2 : (pc+1, store_1 ); 3 : (pc+1, load_0 ); 4 : (pc+1, dup ); 5 : (pc+1, getfield_220 ); 6 : (pc+1, load_1 ); 7 : (pc+1, op ); 8 : (pc+1, putfield_220 ); 9 : (-1, return); }; The following section of the SMV model describes the e ect of the instructions on the variables. The instructions compute levels for each variable. The load instruction pushes the level of a memory location on the stack, the store instruction pops the top of the stack and stores this level in a memory location, the dup instruction duplicates on the stack the top of the stack. The op instruction computes the least upper bound of the levels of the two rst locations of the stack. The least upper bound of levels l1 and l2 is modelled by the disjunction of two levels l1 _ l2. The invoke instruction pops from the stack the parameter and pushes onto the stack the result of this method invokation. According to the assume-guarantee discipline, we assume that the level of the result of method getbalance is L:AF ^L:RC. Instruction getfield pushes on the top of the stack the level of attribute ExtendedBalance that is L:AF . And, nally, instruction putfield pops from the stack the level of attribute ExtendedBalance. switch(ByteCode) { nop :; load_0 : {next(stck[sP]):= mem[0];next(sP):=sP-1;} load_1 : {next(stck[sP]):= mem[1];next(sP):=sP-1;} store_1 : {next(mem[1]):=stck[sP+1] ;next(sP):=sP+1;} dup : {next(stck[sP]):= stck[sP+1]; next(sP):=sP-1;} op : {next(stck[sP+2]):=(stck[sP+1]|stck[sP+2]); next(sP):=sP+1}; invoke_108 : {next(stck[sP]):=L.AF & L.RC;next(sP):= sP+1;} getfield_220 : {next(stck[sP+1]):=L.AF;} 9 putfield_220 : {next(sP):=sP+2;} return : ; } Invariant We explained above how to compute a level for each variable. We also explained what security level we assigned to attributes and interactions. The invariant we verify is then that the computed level of variables we want to control is always lower than the authorized level. For the logfull method we should check two properties : one to veri y that the interaction between logfull and getbalance is correct and the other one to check that logfull correctly uses attribute ExtendedBalance. Property Smethod 108 means that, whenever the current instruction is the invokation of method getbalance, then the level of the transmitted parameters (the top of the stack) is dominated by the level of the interaction AF +RC. Property Sfield 220 means that, whenever the current instruction is the modi cation of eld ExtendedBalance, then the level of the new value (the top of the stack) is dominated by the level of the attribute AF . As logfull does not return any value, there is no need to verify property Sresult which means that whenever the method is nished the level of the return value (the top of the stack) is dominated by the level of the interaction AF + P Smethod_108 : assert G (ByteCode=invoke_108 ->(stck[sP+1] -> L.AF & L.RC)); Sfield_220 : assert G (ByteCode=putfield_220 ->(stck[sP+1] -> L.AF)); Sresult : assert G (ByteCode=return -> (stck[sP+1] -> L.AF & L.P)); 4.3 Analysis Example Once we have the abstract model and the invariant, we model check the invariant properties on the model using SMV [8]. If the property does not hold the model checker produces a counter-model that represents an execution of the byte code leading to a state where the property is violated. A security problem will be detected when checking property Smethod 108 of method logfull. Indeed, the logfull interaction between purse and Air France has AF +P level. The getbalance channel has AF +RC level and we detect that the invocation of the getbalancemethod depends on the invocation of the logfull method. There is thus an illicit dependency from a variable of level AF + P to an object of level AF +RC (cf gure 6). 10 Purse loyalty Air France loyalty RentaCar Purse getBalance getTrsgetTrsloyaltyloyaltylogFullAF+PAF+RCFig. 6. Illicit interaction detection5 ConclusionIn this paper, we have presented an approach for the certi cation of appletsthat are to be loaded on a Javacard. The security checks we propose arecomplementary to the security functions already present on the card. Theapplet rewall controls the interaction between two applets, while our analysishas a more global view and is able to detect illicit information ow betweenseveral applets.5.1 Related workA lot of work has been going on about security and Java, but to our knowl-edge, it does not deal with security properties as we understand it in thispaper (illicit interactions). Instead, they are concerned with properties likecorrect typing, no stack over ow, etc. One exception is [6] which proposes averi cation of control ows, but does not deal with information ow.Among this work, two kinds of approaches can be distinguished dependingon the technique used for the veri cation. Most of the approaches are basedon static analysis techniques, particularly type systems [2,10]. One approachhas used model checking (with SMV) to specify Java byte code [9] but, again,to verify a di erent kind of properties.5.2 Future workFuture work includes the automatization of the production of an SMV modelfrom Java byte code. However, a complete automatization is hardly possible:an interaction with the user will be needed for the de nition of levels (forinteractions and attributes).Another interesting issue is the analysis of results. When SMV producesa counter-example for a security property, we have to study how to interpretthis counter-example at the application level.11 References[1] P. Bieber and F. Cuppens. A Logical View of Secure Dependencies. Journal ofComputer Security, 1(1):99{129, 1992.[2] Stephen N. Freund and John C. Mitchell. A type system for object initializationin the Java byte code language. In Proceedings of OOPSLA 98, 1998.[3] Pierre Girard. Which security policy for multiapplication smart cards? InUSENIX workshop on smartcard technology, 1999.[4] J. Goguen and J. Meseguer. Unwinding and Inference Control. In IEEESymposium on Security and Privacy, Oakland, 1984.[5] Pieter H. Hartel, Michael J. Butler, and Moshe Levy. The operational semanticsof a Java secure processor. Technical Report DSSE-TR-98-1, Declarativesystems and Software Engineering group, University of Southampton,High eld,Southampton SO17 1BJ, UK, 1998.[6] T. Jensen, D. Le M etayer, and T. Thorn. Veri cation of control ow basedsecurity policies. In Proceedings of the 20th IEEE Security and PrivacySymposium, 1999.[7] T. Lindholm and F. Yellin. The Java Virtual Machine Speci cation. AddisonWesley, 1997.[8] K.L. McMillan. The SMV language. Cadence Berkeley Labs, 1999.[9] Joachim Posegga and Harald Vogt. O ine veri cation for Java byte code usinga model checker. In Proceedings of ESORICS, number 1485 in LNCS. Springer,1998.[10] Raymie Stata and Martin Abadi. A type system for Java bytecode subroutines.In Proc. 25th Symposium on Principles of Programming Languages, 1998.[11] Sun Microsystems. Java Card 2.1 Realtime Environment (JCRE) Speci cation,February 1999.12